Companion Guide for Test Automation

Visa Tap to Consumer Device (VTTCD) Test Plan

Version 1.2 | Sept 2025

Important Note on Confidentiality, Disclaimers and Copyright

© 2025 Visa. All Rights Reserved.

Confidentiality: This document, and the information set out in this document, is proprietary and CONFIDENTIAL to Visa. It is distributed to you by Visa as a participant in the Visa payments system for your use only to the extent necessary to enable Visa programs. You acknowledge that the information contained herein (the 'Information') is confidential and subject to confidentiality restrictions contained in Visa's operating regulations or other confidentiality agreements that limit your use of the Information. In no event may this document or its information be duplicated, published, distributed, or disclosed, in whole or in part, to any third party, individual, or any other person, without prior written permission from Visa, and without expressly limiting by way of contract that person's use of this document and the information it contains to assisting you in managing your Visa programs. This document and the information set out in this document may not be used in connection with, or to support, any non-Visa programs or any non-Visa payment network, system, or scheme, including any non-Visa program that is co-badged or co-resident with a Visa program, in each case, without Visa's prior written consent.

Trademarks: The trademarks, logos, trade names and service marks, whether registered or unregistered (collectively the "Trademarks") are Trademarks owned by Visa. All other trademarks not attributed to Visa are the property of their respective owners.

THIS PUBLICATION IS PROVIDED ON AN "AS IS", "WHERE IS", BASIS, "WITH ALL FAULTS" KNOWN AND UNKNOWN. TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, VISA EXPLICITLY DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, REGARDING THE LICENSED WORK AND TITLES, INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AND NON-INFRINGEMENT.

THE INFORMATION CONTAINED HEREIN IS PROPRIETARY AND CONFIDENTIAL AND MUST BE MAINTAINED IN CONFIDENCE IN ACCORDANCE WITH THE TERMS AND CONDITIONS OF THE SPECIFICATION LICENSE OR OTHER WRITTEN AGREEMENT BETWEEN YOU AND VISA INC., VISA INTERNATIONAL SERVICE ASSOCIATION, AND/OR VISA EUROPE LIMITED.

Table of Contents

• Document Version History
• Introduction
• General Information
  • Audience
  • Reference Materials
  • Definitions and Acronyms
• Companion Guide: Checklist
  • I. General Requirements
  • II. Automation Requirements
    • Reader Controller Software
    • Kernel Software
    • Host Simulator
  • III. Scenarios Testing
  • A. Single Run
    • Steps to Perform the Single Run Test
  • B. Batch Runs
    • Steps to Perform the Batch Run Test
    • Batch Run - Test 1 to 20
• 1 Overview
  • 1.1 Automation Setup (Automated Testing)
• 2 Automation Requirements
  • 2.1 Reader Controller
  • 2.2 Test Message
    • 2.2.1 Transaction Configuration (STXN)
  • 2.2.2 Transaction Outcome (ETXN)
  • 2.3 Kernel Integration
  • 2.4 Transaction Configuration
    • 2.4.1 General
    • 2.4.2 Expected Host Response
• 3 Online-Only
• 4 AID
• 5 Date Time Requirement
• Appendix A Test Message
  • A.1 Overview
  • A.2 HTTP Message
  • A.3 Start of Transaction (STXN)
  • A.4 End of Transaction (EXTN)
  • A.5 ECHO
  • A.6 Scenarios and Error Handling
    • A.6.1 General - No Host Response
    • A.6.2 General - Bad Request Format
    • A.6.3 General - Server Busy, Request Timeout
    • A.6.4 General - Error Message
    • A.6.5 Connection and Messaging Protocol Test
    • A.6.6 Test Execution
    • A.6.7. Test Execution - Stop on Error
    • A.6.8 Multiple Start of Transaction (STXN) Messages
    • A.6.9 Multiple End of Transaction (ETXN) Messages
    • A.6.10 End of Transaction (ETXN) Message with Wrong Test_ID
    • A.6.11 Echo in Between Messages
    • A.6.12 Unexpected Flow of Message
• Appendix B Reader Status and Event
  • B.1 Outcome Events
  • B.2 Other Events
  • B.3 Additional Checks
• Appendix C Reader Controller Verifier Tool
• Appendix D Frequently Asked Questions (FAQ)
  • D.1 General
  • D.2 Architecture and Protocol Handling
  • D.3 Product Features and Configurations

Document Version History

Document Version History

Date	Version Number	Description
June 2024	1.0	First publication
March 2025	1.1	Reference Materials Updated Reference Materials Table Table A-2 'XML Elements within <AcquirerData>' Replaced DE_4F element and content with DE_84 Added DE_9F6C Chapter 4 AID Removed the mention of Tag 9F06
Sept 2025	1.2	Companion Guide Checklist Added 2 new test cases Transaction Configuration, Date Time Requirement, AID Allow Reader Controller to configure Transaction Date (Tag 9A) and Application Identifier (Tag 9F06) during test execution New chapter for Date Time Requirement information. Outcome If output of ASRPD and VISA Fleet Data Objects is supported, include this as a conditional output for expected acquirer data. Various editorial updates

Introduction

This document serves as a companion guide for kernel implementations to support the testing automation designed for Visa Tap to Consumer Device Kernel Specification (VTTCD) Level 2 Type Approval.

The automation requirements described in this document are designed solely for testing purposes only.

General Information

Audience

This document is intended for Product Vendors that are seeking Visa recognition of their Tap to Consumer Device kernel (VTTCD) implementations.

Reference Materials

Reference	Document
VCPS	Visa Contactless Payment Specification (VCPS) Version 2.2, and all published updates
VTTCD	Visa Tap to Consumer Device Kernel Specification (VTTCD) Version 1.1 and all published updates
VTTCD Test Plan	VTTCD Test Plan
Test Tool Technical Requirements	Visa Test Tool Technical Requirements for Reader Test Plans Version 1.0 and all published updates
EMV SB 230	EMV Specification Bulletin No. 230 Technical Information to Enhance Contactless Application Selection

Definitions and Acronyms

Acronym	Definition
AOSA	Available Offline Spending Amount
DE	Data Element
Device Applications	A Kernel or Embedded Software loaded into a Physical Device/Reader/Terminal
ODA	Offline Data Authentication
Product Provider	The entity that submits a Visa product to Visa for Type Approval
RC Verifier	Reader Controller Verifier Software
Test Case	A description of the actions required to achieve a specific test objective
Test Tool Vendor	An entity that submits a test tool to Visa for recognition
Type Approval	Verification by Visa that a specific product has demonstrated sufficient conformance to the Visa specifications

Companion Guide: Checklist

This form serves as a checklist for the usage of VTTCD Test Plan and compliance with its automation requirements. Go through the checklist to ensure compliance with all the requirements for test automation.

I. General Requirements

Answer YES or NO to each question.

YES / NO	Question
YES / NO	Does the product support Online-only feature? (Refer to Chapter 3 Online-Only Readers)

II. Automation Requirements

Answer YES or NO to each question for below sections.

Reader Controller Software

Does the Reader Controller Software:

YES / NO	Question
YES / NO	Implement Test Messages STXN, ETXN and ECHO? (Refer to Section 2.2 Test Message and Appendix A Test Message)
YES / NO	Implement the applicable scenarios and error handling described for Test Message protocol? (Refer to Appendix A.6 Scenarios and Error Handling)
YES / NO	Implement ALL the Configuration tags in STXN message when supported? (Refer to Section 2.2.1 Transaction Configuration (STXN) and Section 2.4 Transaction Configuration)
YES / NO	Implement ALL the Transaction Details tags in ETXN message when supported? (Refer to Section 2.2.2 Transaction Outcome (ETXN) and A.4 End of Transaction (EXTN))
YES / NO	Provide an interface to configure number of retries and delay in milliseconds in between Test Messages? (Refer to Appendix A.6.3 General - Server Busy, Request Timeout)
YES / NO	Provide an interface to test the communication channel to/from the server (using ECHO)? (Refer to Appendix A.5 ECHO)
YES / NO	Provide an interface to configure the IP Address and Port of the host that it can connect to? (Refer to Appendix A Test Message)

Kernel Software

Does the Kernel Software interface interact with the Reader Controller Software to:

YES / NO	Question
YES / NO	Receive the equivalent STXN Transaction Configuration?
YES / NO	Auto start the transaction?
YES / NO	Provide the Transaction Details after a transaction is performed? (Refer to Section 2.3 Kernel Integration)

Host Simulator

Does the Host Simulator interact with the Reader Controller Software to:

YES / NO	Question
YES / NO	Receive and configure the Expected Host Response from STXN message? (Refer to Section 2.4.2 Expected Host Response)

III. Scenarios Testing

The scenario checks described in this section is designed for the Reader Controller software to run with the Visa-complimentary Reader Controller Verifier Software (see Appendix A for usage) and a Test Card (provided upon request).

All tests verdicts shall be a PASS or NA (NA only if feature is not supported) to ensure compliance with automation requirements.

A. Single Run

Single run test cases are designed to be executed one-by-one following the messaging protocol for single run (Appendix A.6.6a Single Run). The test cases are designed to try out variations of transaction configuration and transaction outcomes.

Steps to Perform the Single Run Test

For each test case:

1. Assess the Applicability (column 3), if all the features are supported then the test can be performed else mark in the verdict (column 5) as NA. All NOT SUPPORTED features for VTTCD are by default answered NA.
2. If the test can be performed, select the scenario and test case from the RC Verifier and press RUN.
3. Mark the test verdict (column 5):
   • If the test passed with RC Verifier and Visual Check requirements (column 4) are met, mark as PASS. Otherwise, mark as FAIL.

Test ID	Test Case Description	Applicability	Visual Check Requirements	Verdict: PASS / FAIL / NA
Test_01	$2.00 purchase transaction	Applicable for all	None	User to update verdict
Test_02	$2.00 purchase transaction (Online)	Applicable for all	None	User to update verdict
Test_03 through Test_19	NA	NA	NA	NA
Test_20	Update Terminal AID (Tag 9F06)	Applicable for all	None	User to update verdict

B. Batch Runs

Batch run scenarios are designed to execute test cases in batches following the messaging protocol for Batch run (Appendix A.6.6b Batch Run) and Server Busy tests (Appendix A.6.3). These test cases are designed to run in full automation and does not require visual checks.

Steps to Perform the Batch Run Test

For each scenario:

1. Select the scenario from the RC Verifier and press RUN.
2. Mark the test verdict column:
   • If the test passed with RC Verifier, mark as PASS. Otherwise, mark as FAIL.

Batch Run - Test Batch 1 to 5

Scenario/Test ID	Verdict: PASS / FAIL
Test_Batch_01	User to update verdict
Test_Batch_02	User to update verdict
Test_Batch_03	User to update verdict
Test_Batch_04	User to update verdict
Test_Batch_05	User to update verdict

Batch Run - Server Busy at Beginning

Scenario/Test ID	Verdict: PASS / FAIL
Test_Batch_01	User to update verdict
Test_Batch_02	User to update verdict
Test_Batch_03	User to update verdict
Test_Batch_04	User to update verdict
Test_Batch_05	User to update verdict

Batch Run - Server Busy at Middle

Scenario/Test ID	Verdict: PASS / FAIL
Test_Batch_01	User to update verdict
Test_Batch_02	User to update verdict
Test_Batch_03	User to update verdict
Test_Batch_04	User to update verdict
Test_Batch_05	User to update verdict

Batch Run - Test 1 to 20

Batch run (Test 1 to Test 20) scenario is designed to test the robustness of the implementation of messaging protocol. These test cases are derived from Single Run. Reader Controller will run ALL of the following test cases in Batch Run Mode. The same applicability shall be employed and mark the test case as NA if not applicable. Visual checking is not required while running this test.

Steps to perform the test:

1. Assess the applicability; the same applicability shall be applied based from Single Run test cases.
   • Mark the non-applicable test case as NA. NOT SUPPORTED features for VTTCD are by default answered NA.
2. Select Batch Run - Test 1 to 20 scenario from the RC Verifier and press RUN.
3. Mark the test verdict column:
   • If the test is NA, ignore the verdict from RC Verifier.
   • If the test is applicable, check the verdict from RC Verifier and mark as PASS or FAIL.

Batch Run - Test 1 to 20

Scenario/Test ID	Verdict: PASS / FAIL / NA
Test_01	User to update verdict
Test_02	User to update verdict
Test_03	NA
Test_04	NA
Test_05	NA
Test_06	NA
Test_07	NA
Test_08	NA
Test_09	NA
Test_10	NA
Test_11	NA
Test_12	NA
Test_13	NA
Test_14	NA
Test_15	NA
Test_16	NA
Test_17	NA
Test_18	NA
Test_19	NA
Test_20	User to update verdict

1 Overview

This document describes the automation requirements for Visa Tap to Consumer Device Kernel Specification (VTTCD) Level-2 Type Approvals.

This document provides information how the Test Plan materials shall be used and the technical requirements for Products in order to achieve automation.

For Test Tools, a separate document Test Tool Technical Requirements is available to describe the usage of VTTCD Test Plan into their development.

1.1 Automation Setup (Automated Testing)

This figure describes the role of 3 entities in test automation:

• Test Tool
• Reader Controller (provided by the product vendor)
• Physical Reader (product-under-test)

On a high level, the Test Tool:

• Communicates with the Reader Controller to deliver transaction configurations and receive transaction outcomes.
• Provides card emulation of any form (e.g. via card probe or via physical card) that is to be used for each test case execution.
• Provides UI guidance to the test executor such as:
  • ICS declaration form entry
  • Displaying test steps and instructions to perform a test
  • Displaying user prompts to confirm status, events and visual checks
  • Displaying the test verdict
• Validate the APDUs and transaction outcomes
  
  

On a high level, the Reader Controller:

• Communicates with the Test Tool to receive the transaction configuration and pass it to the Physical Reader.
  • Note:Transaction Configuration in this figure represents the content of Start-of-Transaction message response as described in Appendix A
• Retrieves the Transaction Outcome from the Physical Reader and subsequently submit this information to the Test Tool.
  • Note:Transaction Outcome in this figure represents the content of End-of-Transaction message request as described in Appendix A
    
    

On a high level, the Physical Reader/Terminal (i.e. product-under-test):

• Communicates with the Reader Controller to receive transaction configuration
  • Note: Transaction Configuration in this figure represents the content of Start-of-Transaction message response as described in Appendix A
• Performs transaction based on the transaction configuration
• Submits transaction outcome to the Reader Controller
  • Note: Transaction Outcome in this figure represents the content of End-of-Transaction message request as described in Appendix A Test Message
    
    

Both the Test Tool and Reader Controller follows the Test Message protocol as defined in Appendix A Test Message

Messaging between the Reader Controller and the Physical Reader is vendor proprietary and is out of scope from this document.

2 Automation Requirements

The following are the requirements that the VTTCD implementation shall follow to meet the automation requirements.

2.1 Reader Controller

The Product Provider shall submit a "Reader Controller" software that communicates with the Test Tool as described in Figure 1.

The "Reader Controller" software shall be developed as an external kernel or external application from Product-Under-Test.

The "Reader Controller" software may or may not reside inside the payment acceptance device.

All "Reader Controller" software and all its parts shall be removed after testing has completed.

Note: A VISA-complimentary software "Reader Controller Verifier" is a tool provided together with the VTTCD Test Plan package to assist in the Reader Controller developments. This software mimics the "Server" part of the communication protocol as defined in Appendix A along with simulation of various scenarios defined in Section A.6. Details about this tool is discussed in Appendix A.

2.2 Test Message

The "Reader Controller" software shall implement the Test Message requirements as defined in Appendix A. Some additional notes below for implementation of Test Message:

2.2.1 Transaction Configuration (STXN)

During a Start of Transaction (STXN) message exchange, the Reader Controller software receives a string in XML Format. The XML will have a root tag <Configuration> that contains the transaction configuration that needs to be interpreted by the Reader Controller to meet the testing requirements. This includes dynamic configuration of the following:

1. Physical Reader-Terminal and;
2. Host Simulator (Optional to Product vendors)

See section 2.4 Transaction Configuration for the full details of the <Configuration> tag.

2.2.2 Transaction Outcome (ETXN)

At the end of each transaction, the Reader Controller software shall be able to extract the Transaction Outcome from the product-under-test. The transaction outcome is the resultant outcome of a transaction from the Reader-Terminal regardless of the card response. The outcome code and Acquirer Data along with the Test_ID shall be sent to the Test Tool via the End of Transaction (ETXN) message.

See Appendix A.4 End of Transaction (EXTN) for ETXN format and content details.

2.3 Kernel Integration

Along with automation, the Physical Reader/Terminal "Kernel" integration may need be modified to support communication with its own "Reader Controller" software as described in Figure 1 to:

1. Apply the Transaction Configuration received from the Reader Controller
2. Auto-start the Transaction based on the received Transaction Configuration
3. Communicate the Transaction Outcome to the Reader Controller

Note: The communication protocol between the "Reader Controller" and "Kernel" is Product Vendor proprietary and is out-of-scope from this document.

2.4 Transaction Configuration

The VTTCD Test Plan uses the <Configuration> XML structure and elements to define a transaction configuration.

Each element shall be evaluated to determine whether the element is associate to a feature. If it is associated to a feature, determine whether the Product supports the feature.

If an element is associated to a feature OR if the associated feature of the element is supported by the reader, (for example, <DRL> element is tied to DRL feature and the feature is supported), then that element shall be made configurable by the Product Provider through Reader Controller.

Else, if the associated feature of an element is not supported or is unknown (e.g. <DRL> element is tied to DRL feature and this feature is not supported or an unknown element is present), then that element shall be ignored by the reader all throughout the test plan execution.

Sample <Configuration>

<Configuration Test_ID="T_Sample_01" Config_ID="config_1" Version=" 1.2">
    <General>
        <Tag name="Transaction Currency Code" ID="5F2A">0840</Tag>
        <Tag name="Transaction Currency Exponent" ID="5F36">02</Tag>
        <Tag name="Transaction Type" ID="9C">01</Tag>
        <Tag name="Amount, Authorized (Numeric)" ID="9F02">000000000200</Tag>
        <Tag name="Amount, Other (Numeric)" ID="9F03">000000000000</Tag>
        <Tag name="Terminal Country Code" ID="9F1A">0840</Tag>
        <Tag name="Terminal Floor Limit" ID="9F1B"/>
        <Tag name="Merchant Name and Location" ID="9F4E"/>
        <Tag name="Online-Only Reader Enabled" ID="ONLINE_ONLY_READER_ENABLED">True</Tag>
        <Tag name="AUC, Manual Cash Check Enabled" ID="AUC_MANUAL_CASH_CHECK_ENABLED">False</Tag>
        <Tag name="AUC, Cashback Check Enabled" ID="AUC_CASHBACK_CHECK_ENABLED">False</Tag>
        <Tag name="IRWIN, Do Not Transmit" ID="IRWIN_DO_NOT_TRANSMIT"/>
        <Tag name="POI Information" ID="8B"/>
        <Tag name="Merchant Category Code" ID="9F15"/>
        <Tag name="TTQ - MSD Support" ID="TTQ_MSD_SUPPORT">False</Tag>
        <Tag name="TTQ - qVSDC Support" ID="TTQ_QVSDC_SUPPORT">True</Tag>
        <Tag name="TTQ - Offline Only Reader" ID="TTQ_OFFLINE_ONLY_READER">False</Tag>
        <Tag name="TTQ - Online PIN Support" ID="TTQ_ONLINE_PIN_SUPPORT">False</Tag>
        <Tag name="TTQ - Signature Support" ID="TTQ_SIGNATURE_SUPPORT">False</Tag>
        <Tag name="TTQ - ODA For Online Authorization Support" ID="TTQ_ODA_FOR_ONLINE_AUTHORIZATION_SUPPORT">False</Tag>
        <Tag name="TTQ - Mobile Functionality CDCVM Support" ID="TTQ_MOBILE_FUNCTIONALITY_CDCVM_SUPPORT">True</Tag>
    </General>
    <Exception_File_Check Enabled="False"/>
    <Pre-processing Enabled="False"/>
    <DRL Enabled="False"/>
    <Expected_Host_Response/>
    <Certification_Revocation_List/>
    <Online_ODA/>
</Configuration>

Table 2-1: XML Elements and Attributes within <Configuration>

XML Element / Attribute	Description	Presence	Example Value
Configuration	Container element for Transaction Configuration Mandatory Contains below static elements (always present): <General> <Exception_File_Check> <Pre-processing> <DRL> <Expected_Host_Response> <Certification_Revocation_List>	Mandatory	--
Version	An attribute that contains the version of the contents of <Configuration>. This attribute is informational only and facilitates the version of the structure of transaction configurations. This document follows Version 1.3	Optional	1.3
Info	An attribute that contains information of the test. This attribute is informational only.	Optional	"VTTCD Test Plan v1.0a,VTTCD_Default"
Test_ID	The test case identifier	Mandatory	"T_5_85_C01_01"
Config_ID	The equivalent configuration file identifier config_<running number>.xml. Test cases using the same unique Config_ID uses the same configuration details. Note: Reader applications can use this identifier to control and minimize parameter updates to the reader-terminal and/or host simulators.	Mandatory	"config_1"
General	Container element that contains the general configuration expected from both the reader-terminal and the transaction. Always contain the following Tag IDs: 5F2A (Transaction Currency Code) 5F36 (Transaction Currency Exponent) 9C (Transaction Type) 9F02 (Amount, Authorized (Numeric)) 9F03 (Amount, Authorized Other (Numeric)) 9F1A (Terminal Country Code) 9F1B (Terminal Floor Limit) 9F4E (Merchant Name and Location) 9A (Transaction Date) 9F06 (Terminal Application Identifier) ONLINE_ONLY_READER_ENABLED AUC_MANUAL_CASH_CHECK_ENABLED AUC_CASHBACK_CHECK_ENABLED IRWIN_DO_NOT_TRANSMIT (kept for completeness, this element is no longer in use) TTQ_MSD_SUPPORT TTQ_QVSDC_SUPPORT TTQ_OFFLINE_ONLY_READER TTQ_ONLINE_PIN_SUPPORT TTQ_SIGNATURE_SUPPORT TTQ_ODA_FOR_ONLINE_AUTHORIZATION_SUPPORT TTQ_MOBILE_FUNCTIONALITY_CDCVM_SUPPORT And may conditionally contain the following tag IDs: 8B (POI Information) 9F15 (Merchant Category Code)	Mandatory	--
Tag	Represents a data element. Can appear multiple times within container elements. Appears under the following elements: General - always present Reader_Limit_Set - only present when attribute Enabled ="True" Expected_Host_Response - only present when this container element is not empty	Conditional	0840, True, False, None Note: Tag data type can be either Hex value or Boolean or None. Empty enclosing tag <Tag/> means the configuration element shall be ignored (i.e. if the configuration exists, no change is needed and if configuration does not exist, ignore).
name	Attribute name under <Tag> element. Always present.	Mandatory	"Transaction Currency Code"
ID	Attribute ID under <Tag> element that refers to the equivalent Tag ID used by the test plan or specification. Always present.	Mandatory	"5F2A"
Exception_File_Check	Not used for VTTCD	Mandatory	Empty
Enabled	Attribute that represents whether the data element or feature is enabled or disabled for test case execution. Enabled="True" means the feature or data element shall be enabled and its value changed. Enabled="False" means that the feature or data element shall be disabled if supported or ignored if not supported.	Mandatory	"True", "False"
Pre-processing	Not used for VTTCD	Mandatory	Empty
DRL	Not used for VTTCD	Mandatory	Empty
Expected_Host_Response	A static container element that represents the Host Response expected from the Host Simulator. It is the duty of the Reader Controller to pass this information to the Host Simulator. When this element is a closed tag <Expected_Host_Response/>, means that by default the Authorization Response Code (tag '8A') is "00" without Issuer Authentication Data (tag ‘91’) and without Issuer script template. Otherwise, the Host Response requires customization and contains the following tag IDs: 8A (Authorization Response Code) 91 (Issuer Authentication Data) ISSUER_SCRIPT (Issuer Script template, may contain either Template 71 or Template 72)	Mandatory	--
Certification_Revocation_List	Not used for VTTCD	Mandatory	Empty
Online_ODA	Not used for VTTCD	Mandatory	Empty

2.4.1 General

Sample <General> element within <Configuration>

<Configuration Test_ID="T_5_85_C01_01" Config_ID="config_1" Info="VTTCD Test Plan v1.0a,VTTCD_Default" Version="1.2">
<General>
<Tag name="Transaction Currency Code" ID="5F2A">0840</Tag>
<Tag name="Transaction Currency Exponent" ID="5F36">02</Tag>
<Tag name="Transaction Type" ID="9C">01</Tag>
<Tag name="Amount, Authorized (Numeric)" ID="9F02">000000000200</Tag>
<Tag name="Amount, Other (Numeric)" ID="9F03">000000000000</Tag>
<Tag name="Terminal Country Code" ID="9F1A">0840</Tag>
<Tag name="Terminal Floor Limit" ID="9F1B"/>
<Tag name="Merchant Name and Location" ID="9F4E"/>
<Tag name="Online-Only Reader Enabled" ID="ONLINE_ONLY_READER_ENABLED">False</Tag>
<Tag name="AUC, Manual Cash Check Enabled" ID="AUC_MANUAL_CASH_CHECK_ENABLED">False</Tag>
<Tag name="AUC, Cashback Check Enabled" ID="AUC_CASHBACK_CHECK_ENABLED">False</Tag>
<Tag name="IRWIN, Do Not Transmit" ID="IRWIN_DO_NOT_TRANSMIT"/>
<Tag name="POI Information" ID="8B">0001020001</Tag>
<Tag name="Merchant Category Code" ID="9F15">9999</Tag>
<Tag name="TTQ - MSD Support" ID="TTQ_MSD_SUPPORT">False</Tag>
<Tag name="TTQ - qVSDC Support" ID="TTQ_QVSDC_SUPPORT">True</Tag>
<Tag name="TTQ - Offline Only Reader" ID="TTQ_OFFLINE_ONLY_READER">False</Tag>
<Tag name="TTQ - Online PIN Support" ID="TTQ_ONLINE_PIN_SUPPORT">False</Tag>
<Tag name="TTQ - Signature Support" ID="TTQ_SIGNATURE_SUPPORT">False</Tag>
<Tag name="TTQ - ODA For Online Authorization Support" ID="TTQ_ODA_FOR_ONLINE_AUTHORIZATION_SUPPORT">False</Tag>
<Tag name="TTQ - Mobile Functionality CDCVM Support" ID="TTQ_MOBILE_FUNCTIONALITY_CDCVM_SUPPORT">True</Tag>
</General>
…
</Configuration>

Table 2-2: Tags Present in <General>

Tag ID (Description)	Example Value	ICS Feature Dependency	Remarks
5F2A (Transaction Currency Code)	0840	--	--
5F36 (Transaction Currency Exponent)	02	--	--
9C (Transaction Type)	00	--	--
9F02 (Amount, Authorized (Numeric))	000000000200	--	--
9F03 (Amount, Authorized Other (Numeric))	000000000000	Cashback feature supported	--
9F1A (Terminal Country Code)	0840	--	--
9F1B (Terminal Floor Limit)	--	NOT SUPPORTED for VTTCD	--
9F4E (Merchant Name and Location)	--	NOT SUPPORTED for VTTCD	--
9A (Transaction Date in YYMMDD format) (If a value is set, use this value to configure the Transaction Date. Otherwise, use the Reader-Terminal current date as the Transaction Date)	250930	--	--
9F06 (Terminal Application Identifier) (If a value set, use this value as the AID(s) to be supported by the Reader-Terminal. The value is expressed in an array form with a maximum of up to 10 values. Otherwise, use A000000003 as the default AID)	[A000000003, B0000000031010,B000000003101001]	--	--
ONLINE_ONLY_READER_ENABLED (Configuration to Enable or Disable the Online-Only processing feature of the Reader-Terminal)	True (always)	--	--
AUC_MANUAL_CASH_CHECK_ENABLED (Configuration to Enable or Disable the processing restriction for Manual Cash transactions as described in VCPS Req 5.76])	False (always)	NOT SUPPORTED for VTTCD	--
AUC_CASHBACK_CHECK_ENABLED (Configuration to Enable or Disable the processing restriction for Cashback transactions as described in VCPS Req 5.77])	False (always)	NOT SUPPORTED for VTTCD	--
IRWIN_DO_NOT_TRANSMIT (Instruction to not transmit the given DE tag within IRWIN Message, the example value 57 means do not transmit tag ‘57’ Track 2 Equivalent Data within IRWIN Message)	NA	--	--
TTQ_MSD_SUPPORT (Configuration to Enable or Disable the MSD support feature as in TTQ B1b8, always False for VCPS)	False (always)	--	--
TTQ_QVSDC_SUPPORT (Configuration to Enable or Disable the qVSDC support feature as in TTQ B1b6, always True for VCPS)	True (always)	--	--
TTQ_OFFLINE_ONLY_READER (Configuration to Enable or Disable the Offline-Only processing feature of the reader as in TTQ B1b4)	False (always)	--	--
TTQ_ONLINE_PIN_SUPPORT (Configuration to Enable or Disable the Online PIN CVM feature as in TTQ B1b3)	True (always)	--	--
TTQ_SIGNATURE_SUPPORT (Configuration to Enable or Disable the Signature CVM feature as in TTQ B1b2)	True (always)	--	--
TTQ_ODA_FOR_ONLINE_AUTHORIZATION_SUPPORT (Configuration to Enable or Disable the ODA for Online support feature as in TTQ B1b1)	False (always)	--	--
TTQ_MOBILE_FUNCTIONALITY_CDCVM_SUPPORT (Configuration to Enable or Disable the Mobile Functionality support (CD CDVM) as in TTQ B3b7, always True for VCPS)	True (always)	--	--
8B (Kept for completeness. Not used in VTTCD).	None	NOT SUPPORTED for VTTCD	--
9F15 (Kept for completeness. Not used in VTTCD)	None	NOT SUPPORTED for VTTCD	--

2.4.2 Expected Host Response

<Expected_Host_Response> element contains the customized expected response from Product Provider’s Host Simulator. This container element contains sub elements only when the test case needs to simulate a customized host response. When sub elements are present, the Host Simulator shall be configured to manipulate the Host Response according to the sub elements (Authorization Response Code, Issuer Authentication Data, and/or Issuer Script).

• Note: If automation is supported, the Reader Controller shall communicate the sub elements (Authorization Response Code, Issuer Authentication Data, and/or Issuer Script) details with the Host Simulator to manipulate the Host Response.

A closed tag <Expected_Host_Response/> means that by default the host response shall be an Approval without any Issuer Script Processing.

Sample <Expected_Host_Response> element within <Configuration>:

<Configuration Test_ID="T_5_85_C01_01" Config_ID="config_1">
  ...
  <Expected_Host_Response>
    <Tag name="Authorization Response Code" ID="8A">00</Tag>
    <Tag name="Issuer Authentication Data" ID="91">1234567803820000</Tag>
    <Tag name="Issuer Script" ID="ISSUER_SCRIPT">71169F180400000001860D841E0000081234567890123456</Tag>
  </Expected_Host_Response>
  ...
</Configuration>

Table 2-3: Tags present in <Expected_Host_Response>:

Tag ID (Description)	Example Value	ICS Feature Dependency	Remarks
Expected_Host_Response	--	--	--
8A (Authorization Response Code) The value is a 2-byte string e.g. 00 means ‘3030’ in hex. If the value is set to None, the test expectation is a No Host Response) Note: • 00, 10, or 11 indicates an issuer approval. • 01 or 02 indicates an issuer referral. • An ARC other than the ones listed above indicates an issuer decline.	00, 03, 11, 12, 13, 23, None	--	--
91 (Issuer Authentication Data) If the value is set to None, this means that the Host Simulation shall not return Issuer Authentication Data in the Host Response. Also, the test does not expect the Reader/Terminal to send an EXTERNAL_AUTHENTICATE command at Second Tap)	1234567803820000, None	NOT SUPPORTED for VTTCD	--
ISSUER_SCRIPT (Issuer Script) If the value is set to None, this means that the Host Simulation shall not return Issuer Scripts in the Host Response. Also, the test does not expect the Reader/Terminal to send any ISSUER SCRIPT command at Second Tap)	71169F180400000001860D841E0000081234567890123456, None	NOT SUPPORTED for VTTCD	--

3 Online-Only

VTTCD implementation shall always set TTQ B2b8 (Online Cryptogram Required) to 1b regardless of the Reader Risk Parameter settings specified in <Reader_Limit_Set>.

4 AID

The product-under-test must initialize Tag 9F06 (Application Identifier (AID) - Terminal) with the default value “A000000003”. If an alternate value for tag 9F06 is received by the reader controller, this value shall be overridden with the specified value(s).

Note: As per VCPS Req 5.47, ADF Name matching by full match and by partial match are to be supported and enabled by default.

5 Date Time Requirement

The VTTCD Test Plan is compliant to run with Reader/Terminal internal date time set from June 1, 2017 and onwards.

By default, the product-under-test is expected to use the current date and time to process Tag 9A (Transaction Date). If an alternate value for Tag 9A is received by the reader controller, it shall be overridden with the specified value.

Appendix A Test Message

This section defines the flow, protocol, expectations and message handling between the Reader Controller (herein referred to as "client") and the Test Tool (herein referred to as "server") during the Test Message exchange.

Test Message utilizes the HTTP Protocol that is a TCP/IP based communication protocol. Hence, requires the server application to listen to an open TCP/IP socket (IP Address and Port) and the client application to send/receive HTTP Messages over the open socket. This architecture is synchronous and is applicable only for one-to-one communication with server and client (cannot be one-to-many).

Note: The IP Address and Port shall not be static and shall be made configurable by the client and server applications.

A.1 Overview

A.2 HTTP Message

Throughout the test messaging, below structure of HTTP Request and Response message (as defined in RFC 7230 and RFC 7231) are used. Below tables are for reference only. The parameters and values shown in these tables are recommended but shall not be mandated by the server or client applications.

HTTP – Request message

Entity	Description
Request Line	request-method-name request-URI HTTP-version GET / HTTP/1.1 POST / HTTP/1.1 TRACE / HTTP/1.1
Request Headers	request-header-name: request-header-value1, request-header-value2, ... Message: [Name of message] Host: [IP Address]:[Port] Connection: keep-alive If Request message body exists: Content-Type: text/plain
-	BLANK LINE
Request Message Body	XML Data (Conditional)

HTTP – Response message

Entity	Description
Status Line	HTTP-version status-code reason-phrase HTTP/1.1 200 OK (Other status-codes to be defined)
Response Headers	response-header-name: response-header-value1, response-header-value2, ... Accept-Ranges: bytes Connection: keep-alive If Response message body exists: Content-Type: text/plain
-	BLANK LINE
Response Message Body	XML Data (Conditional)

Note: Requirements for Bad format checks are further discussed in A.6.2 General - Bad Request Format.

Sample Exchange

GET / HTTP/1.1
Message: STXN
Host: localhost:8080
Connection: keep-alive
HTTP/1.1 200 OK 
Date: Wed, 18 Oct 2017 08:56:53 
Accept-Ranges: bytes
Connection: keep-alive 
Content-Length: 116
Content-Type: text/plain

<Configuration Test_ID="T_001"><Tag name="Amount, Authorized (Numeric)" ID="9F02">000000000001</Tag></Configuration>

POST / HTTP/1.1
Message: ETXN
Host: localhost:8080
Connection: keep-alive
Content-Length: 140
Content-Type: text/plain

<Transaction_Details><Test_ID>T_0001</Test_ID><Transaction_Outcome>20</Transaction_Outcome><AcquirerData/><IRWINData/></Transaction_Details>
HTTP/1.1 200 OK 
Date: Wed, 18 Oct 2017 08:57:14 
Accept-Ranges: bytes 
Connection: keep-alive 

A.3 Start of Transaction (STXN)

STXN is a message sent by the Reader Controller to the Test Tool to indicate that the reader-terminal is ready to start a transaction. Reader-Terminal configuration is sent back as the message response.

HTTP Request

Entity	Description	Comments
Request Line	GET/HTTP/1.1	Use GET method
Request Headers	Message: STXN Host: [IP Address]:[Port] Connection: keep-alive	-

HTTP Response

Entity	Description	Comments
Status Line	HTTP/1.1 [status-code reason-phrase]	status-code reason-phrase: 200 OK (success, ACK) 204 No Content (no more test) 400 Bad Request Format (malformed request syntax) 408 Request Timeout (server is busy, try again later) 409 Conflict (multiple updates) Others (server exception)
Response Headers	Connection: keep-alive Content-Type: text/plain	-
Resonse Message Body	XML Data	XML Data that contains the Reader-Terminal Configuration in order to perform the test. See Section 2.4 for the XML content.

A.4 End of Transaction (EXTN)

ETXN is a message sent by the Reader Controller to the Test Tool to indicate that the transaction in the reader-terminal has completed. The Transaction outcome details are submitted to the server as part of the message request.

HTTP Request

Entity	Description	Comments
Request Line	POST/HTTP/1.1	Use POST method
Request Headers	Message: EXTN Host:[IP Address]:[Port] Connection:keep-alive Content-Type: text/plain	-
Request Message Body	XML Data	XML Data that contains the transaction outcome details. See Sample <Transaction_Details> and Table A-1: XML Elements and Attributes within <Transaction_Details> for details

HTTP Response

Entity	Description	Comments
Status Line	HTTP/1.1 [status-code reason-phrase]	status-code reason-phrase: 200 OK (success, ACK) 204 No Content (no more test) 400 Bad Request Format (malformed request syntax) 408 Request Timeout (server is busy, try again later) 409 Conflict (multiple updates) Others (server exception)

Note: A 200 status code is merely an acknowledgement response of the message regardless whether the test case verdict is a pass or fail.

Sample <Transaction_Details>

<Transaction_Details>
   <Test_ID>T_001</Test_ID>
   <Transaction_Outcome>20</ Transaction_Outcome>
   <AcquirerData>  
      <DE_9F02>000000000200</DE_9F02>
      <DE_9F03>000000000000</DE_9F03>
      <DE_9F26>1122334455667788</DE_9F26>
      <DE_82>0020</DE_82>
      <DE_9F36>0001</DE_9F36>
      <DE_5F34>00</DE_5F34>
      <DE_9F7C>010203040500FF</DE_9F7C>
      <DE_9F6E>20400000</DE_9F6E>
      <DE_9F10>06011203A00000</DE_9F10>
      <DE_9F39>07</DE_9F39>
      <DE_9F1A>0840</DE_9F1A>
      <DE_TERMINAL_ENTRY_CAPABILITY>05</DE_TERMINAL_ENTRY_CAPABILITY>
      <DE_95>0000000000</DE_95>
      <DE_5F2A>0840</DE_5F2A>
      <DE_9A>180521</DE_9A>
      <DE_9C>00</DE_9C>
      <DE_9F37>11223344</DE_9F37>
      <DE_9F5B/>
      <DE_9F24/>
      <DE_57>4761739001010010D20122011234599999991F</DE_57>
   </AcquirerData>
   <IRWINData/>
</Transaction_Details>

Table A-1: XML Elements and Attributes within <Transaction_Details>

XML Element / Attribute	Description	Presence	Example Value
Transaction_Details	Container element for Transaction Details below static elements (always present): <Test_ID> <Transaction_Outcome> <AcquirerData> <IRWINData>	Mandatory	-
Test_ID	Contains the Unique Identifier of the test case Note: This shall reflect the equivalent test case ID as received from the STXN message. Otherwise, the server shall decline acknowledgement of ETXN message.	Mandatory	T_001
Transaction_Outcome	Contains a 1-byte representation of the Transaction Outcome in Hex String format. This byte is reset to 0x00 at the beginning of a transaction. The left nibble of the byte indicates the transaction outcome (bits 8-5) ‘0’ = Offline Approval ‘1’ = Offline Decline ‘2’ = Online Approval ‘3’ = Online Decline ‘E’ = Switch ‘F’ = Terminate Others = RFU The right nibble of the byte indicates the reader-terminal verification results (bits 4-1) bit 4: 1 = SDA performed bit 3: 1 = fDDA performed bit 2: 1 = If either SDA/fDDA is performed but unsuccessful/failed, set to 1b bit 1: 1 = If card application is expired, set to 1b Note: Reader-terminal verification results (bits 4-1) are to be populated when transit feature is supported and enabled (if TTQ B1b1 is set to 1b – Transit).	Mandatory	04, 06, 20, 30, E0, F0…
DE_<tag>	DE element that represents a tag and value in a list.	Conditional	<DE_9F02>000000000200</DE_9F02>
AcquirerData	Container element for data elements that are available to the acquirer for inclusion in online messages and clearing records. The reader-terminal is not prohibited from providing other data in addition to the minimum data specified in the list. Acquirer Data shall be populated for all completion outcome status i.e. Offline Approval, Offline Decline, Online Approval and Online Decline transactions. See Table A-2 for the list of Data Elements to be populated. Note: For Switch and/or Terminate transactions this shall be an empty container element <AcquirerData/>	Mandatory	--
IRWINData	(Kept for completeness, this element is no longer in use)	Mandatory	--

All XML Element tags listed below represents the minimum data to be included in <AcquirerData> container element for a transaction.

If the Data Element is available for inclusion in online messages and clearing records, the value shall be populated with Hexadecimal string and left-padded with zeroes ‘0’ to meet the length requirement.

Otherwise, if the data element is not available, the XML element tag shall be populated as a closed tag. Refer to the specification for requirements when the value shall be present or conditional to be present.

Table A-2: XML Elements within <AcquirerData>

XML Element	Description	Length Requirement (in bytes, to be multiplied by 2 when expressed to Hexadecimal string)
DE_84	Dedicated File (DF) Name (AID)	As received from Card response
DE_9F02	Amount, Authorized	6
DE_9F03	Amount, Other	6
DE_9F26	Application Cryptogram	8
DE_82	Application Interchange Profile	2
DE_9F36	Application Transaction Counter (ATC)	2
DE_5F34	Card Sequence Number	1
DE_9F6C	Card Transaction Qualifiers	2
DE_9F6E	Form Factor Indicator	4
DE_9F10	Issuer Application Data	As received from Card response
DE_9F1A	Terminal Country Code	2
DE_95	Terminal Verification Results	5
DE_5F2A	Transaction Currency Code	2
DE_9A	Transaction Date	3
DE_9C	Transaction Type	1
DE_9F37	Unpredictable Number (Reader-Terminal)	4
DE_57	Track 2 Equivalent Data	As received from Card response
DE_96	Kernel Identifier – Terminal	8
DE_9F0A	Application Selection Registered Proprietary Data (ASRPD)	8
DE_BF0C_DF30	VISA Fleet Data Object – Prompting Tag	Var
DE_ BF0C_DF32	VISA Fleet Data Object – Purchase Restrictions	Var
DE_ BF0C_DF40	VISA Fleet Data Object – Generic ID	Var
DE_BF0C_DF41	VISA Fleet Data Object – Vehicle ID	Var
DE_BF0C_DF43	VISA Fleet Data Object – Driver ID	Var
DE_BF0C_DF52	VISA Fleet Data Object – Fleet Trailer Number	Var
DE_BF0C_DF53	VISA Fleet Data Object – Fleet Employee Number	Var
DE_BF0C_DF54	VISA Fleet Data Object – Fleet Work Order/Purchase Order Number	Var
DE_BF0C_DF55	VISA Fleet Data Object – Fleet Additional Prompted Data 1	Var
DE_BF0C_DF56	VISA Fleet Data Object – Fleet Additional Prompted Data 2	Var

Notes:

• DE_96 is mandatory if the product is compliant to the [VCPS APP SELECTION] specifications.
• DE_9F0A and DE_BF0C_[tag id] are optional data and are only required for terminals supporting output of ASRPD and VISA Fleet Data Objects.

A.5 ECHO

ECHO is an administrative message for the Reader Controller to check the end-to-end communication between the client and the server

HTTP Request

Entity	Value	Comments
Request Line	TRACE / HTTP/1.1	Use TRACE method
Request Headers	Message: ECHO Host: [IP Address]:[Port] Connection: keep-alive	-

HTTP Response

Entity	Value	Comments
Status Line	HTTP/1.1 [status-code reason-phrase]	status-code reason-phrase 200 OK (success, ACK) 400 Bad Request Format (malformed request syntax) 408 Request Timeout (server is busy, try again later) Others (fail)
Response Headers	Connection: keep-alive Content-Type: text/plain	-
Response Message Body	[Content of the HTTP Request header(s)]	Echoes back the content of the HTTP Request headers

A.6 Scenarios and Error Handling

A.6.1 General - No Host Response

When a test process begins, Server socket connection shall always be available to the client throughout the duration of the process. Client shall be able to handle when there is no host/server response. This indicates connection failure with the host.

A.6.2 General - Bad Request Format

The Server shall check the message syntax when it receives message from the client (e.g. bad or missing expected request header "Message"). Server shall return 400 Bad Request Format status code, which indicates that the request syntax is malformed.

Message syntax check shall include the following conditions. In the event that any of below condition is not met, the server shall return 400 Bad Request Format:

• Header Message value shall not be null and shall be equal to "STXN", "ETXN" or "ECHO" (case-sensitive).
• ETXN request Message body content shall not be null, and shall contain all following keywords (case-sensitive)
  • <Transaction_Details>
  • </Transaction_Details>
  • <Test_ID>
  • </Test_ID>
  • <Transaction_Outcome>
  • </Transaction_Outcome>
• ETXN request Test ID received should be the same value as the current Test ID (case-sensitive) or the Test ID sent from the last STXN response.

A.6.3 General - Server Busy, Request Timeout

When a client sends a message and the Server is Busy, a 408 Request Timeout status code shall be returned. This indicates that the server is busy and the client can try to re-send the same message later.

Recommended Settings (Below setting constitutes a total of 5 minutes of retries – allows the human tester to view the visual checks and respond accordingly. This setting must be configurable at client side.)

• Delay: 1 second
• Number of retries: 300

Note: For status codes other than 408, automatic retry is not applicable.

A.6.4 General - Error Message

If the status code is not 200 or not 204 or 408 and the number of retries are exhausted (if applicable) then the client shall indicate an error message displaying minimally the "status-code reason-phrase" to the user and terminate the testing process.

A.6.5 Connection and Messaging Protocol Test

A 200 status code for TRACE, Echo means network connection and messaging protocols are both ok. Status code other than 200 indicates further troubleshooting is required.

A.6.6 Test Execution

Below flow summarizes the client-server message exchange during a test execution. Before the test process starts, the server shall prepare the list of Test_IDs to run.

The list of Test_IDs to run depends on the type of run the Test Tool user prefers:

a. Single run – execute a single test case (run-one-by-one)

b. Batch run – execute the full batch of test cases (run-full-batch)

A Test_ID shall adapt a test cycle that minimally consists of three states:

1. begin – the beginning state, where the Test_ID have never been sent or have never been completed.
2. sent – the sent state is where the server receives a Start-of-Transaction message and this Test_ID have been sent to the client.
3. completed – the completed state is when the server receives an End-of-Transaction message for the Test_ID and the response status code is 200 (OK).

When the server has exhausted the list of Test_IDs (i.e. no more test case to run), the server shall respond Start-of-Transaction message with 204 status code.

a. Single Run

b. Batch Run

A.6.7. Test Execution - Stop on Error

The test tool shall have an option for users to enable the Stop-On-Error function. This functionality enables the Test Tool to "pause" the test process when Product-under-test has failed a test. This enables the user to investigate the cause of failure before resuming the test process. When a test process is paused, the test tool shall memorize the test case context so that the process can continue to the next test case when resumed.

When Stop-On-Error function is enabled and a verdict for the last test case is a FAIL, the server shall reply with a 204 status code. A 204 status code shall make the client application stop or pause the test process. When the client application starts again the test process, the server shall respond with the next Test_ID with state == begin.

Note: If the test verdict is not yet available (this is true for some test cases that requires extra Visual Check(s)), the server may reply with "Server is Busy" 408 return code. See Appendix A.6.3.

A.6.8 Multiple Start of Transaction (STXN) Messages

Below illustration shows the expected server behavior when multiple STXN message is received. In this case, the server shall respond with the last Test_ID in "sent" state.

A.6.9 Multiple End of Transaction (ETXN) Messages

Below illustration shows the expected server behavior when multiple ETXN message is received. In this case, the server shall check that the Test_ID is the same with the last Test_ID (where last message is ETXN message). If the Test_ID is the same, the server shall overwrite the transaction outcome from the new ETXN message and shall invoke the Test Tool to re-do validation of the test.

A.6.10 End of Transaction (ETXN) Message with Wrong Test_ID

When the server receives an ETXN message, it shall validate that the Test_ID match the last Test_ID (from the last STXN message or last ETXN message). If it does not match, the server shall reply with 400 status code (Bad Request Format).

A.6.11 Echo in Between Messages

Echo is an administrative message to test end-to-end client-server communication. Test case or test process shall not be affected in any way by an Echo message.

A.6.12 Unexpected Flow of Message

When an incoming message is unexpected by the server (i.e. End-of-Transaction message is received for a Test_ID when test state==begin) the server shall reply 400 status code (Bad Request Format).

Appendix B Reader Status and Event

The following Events and Checks are passing criteria to the VTTCD Test Plan. This section is only informational to Product Providers and serves as a guide for the expected visual checks required for Level 2 Type Approval.

B.1 Outcome Events

Status/Event	Description
EVT_NOTIFY_TERMINATE	The reader (or terminal) shall clearly communicate to the cardholder and merchant the outcome of the transaction - Terminate
EVT_NOTIFY_ANY_COMPLETION_OUTCOME	The reader shall indicate any transaction completion outcome. The reader shall not indicate any error or terminate the transaction.

B.2 Other Events

Status/Event	Description
EVT_UNIQUE_UN_GENERATED	The kernel shall use a unique Unpredictable Number (tag '9F37') for this transaction. NOTE: Tool Vendor may provide a means to supply user with the Unpredictable Number from the Test Session for this check.
EVT_COLLISION_ERROR	The reader shall shall indicate that multiple contactless cards are detected by the reader and shall request placement of a single payment card.
EVT_REQUEST_PRESENT_CARD	The reader shall request for card to be presented
EVT_REMOVE_CARD_IN_PROGRESS	The reader shall indicate to the cardholder and merchant that card read is complete and that the card may be removed, but that the transaction is still in progress.

B.3 Additional Checks

Check	Description
CHK_EXP_ACQ_DATA	Perform check to match the expected Acquirer Data content. Acquirer Data refers to the data objects for possible inclusion to Online Authorization Message and/or Clearing Message to Acquirer. Only the content is required to be matched (whether the data shall be present or shall not be present and if present shall be matched). The actual messaging protocol is out of scope from this document.
CHK_APDU_LOG	Perform check on the APDU log. APDU log refers to the message exchange unit between the "Card" smart card emulation and the smart card Reader referred here as APDU (Application Protocol Data Unit).

Appendix C Reader Controller Verifier Tool

The Reader Controller Verifier tool allows developers to assist in development of their own Reader Controller implementations. This section describes the detailed usage of the tool.

1. Dropdown box to choose a scenario.
2. User toolbar:
   • RUN button to simulate the scenario
   • STOP button to stop the simulation
   • ERASE button to erase the display logs
3. Dropdown box to choose test case to run if running in Single Run mode or the test case to start with if running in Batch Run mode.
4. Non-editable, specifies the server address. By default, this tool can only run in localhost.
5. Specifies the TCP/IP server port to listen to.
6. Server configuration to simulate some of the test messaging scenarios

Scenarios: In order to check the Reader Controller implementation, run all scenarios listed in the List of Compliance Scenarios table below. Other scenarios are available for development purpose and for simulation only.

List of Compliance Scenarios

Scenario	Description/Reference
Single Run	Simulates the Test Execution - Single Run scenario as described in Appendix A.6.6a
Batch Run	Simulates the Test Execution – Batch Run scenario as described in Appendix A.6.6b
Batch Run - Server Busy at beginning	Simulates the Test Execution – Batch Run with Server Busy scenario as described in Appendix A.6.3. The server will be busy at the beginning of the batch run.
Batch Run - Server Busy at middle	Simulates the Test Execution – Batch Run with Server Busy scenario as described in Appendix A.6.3. The server will be busy in the middle of the batch run.

Other Scenarios

Scenario	Description/Reference
Stop on Error	Simulates the server side scenario A.6.7 Test Execution – Stop On Error Note: Available at the settings panel of Reader Controller Verifier tool.
Always No Host Response	Simulates the server side scenario A.6.1 General - No Host Response Note: Available at the settings panel of Reader Controller Verifier tool.
Always Reply Error Message	Simulates the server side scenario A.6.4 General – Error message Note: Available at the settings panel of Reader Controller Verifier tool.
Messaging Protocol Test	By default, these scenarios are handled consciously by the server while running the compliance scenarios: A.6.2 General – Bad Request Format A.6.5 Connection and Messaging Protocol Test A.6.8 Multiple Start of Transaction (STXN) message A.6.9 Multiple End of Transaction (ETXN) message A.6.10 End of Transaction (ETXN) message with wrong Test_ID A.6.11 Echo in between messages A.6.12 Unexpected Flow of Message

Visual Check Requirement: Some of the tests will require Visual Check Requirements confirmations from the user depending on the test requirement. This aims to notify the user to observe the reader/terminal and confirm that it behaves as expected.

Note: Confirmation of visual check requirements is part of the passing criteria for these type of tests.

Test Result:

The test result panel lists down the test cases and indicates a GREEN dot when a test case verdict is a Pass and a RED dot when the test case verdict is a Fail.

In this simulation, the Reader Controller Verifier tool will only compare the Transaction Outcome content from ETXN message against the expected from the test case. The pass/fail verdict does not simulate the entire verdict logic of a test tool that will also include APDU matching and complete visual check validations against Reader Status and Event.

Log files are automatically saved and is available in {user path.visasim.rcverifier}\log folder.

Appendix D Frequently Asked Questions (FAQ)

D.1 General

Q: What does Clearing Record means?

A: The collection and delivery to the issuer of a completed transaction record from an acquirer. The completed transaction can either be Offline Approval, Offline Decline, Online Approval and/or Online Decline transactions.

Q: Will the tester check the APDUs on the Test Tool side or on the terminal side?

A:
The APDUs will be logged and are checked at the Test Tool side.

D.2 Architecture and Protocol Handling

Q: Our Reader Controller implementation does not have a connection to an external Host Simulator. The Reader Controller itself acts as the Host Simulator. Whenever a transaction requests for an online authorization, the equivalent content of <Expected_Host_Response> will be communicated to the terminal directly. Can it be implemented in this way?

A: Yes, this is allowed. There is no restriction where the Host Simulator shall reside.

Q: Is there any special mode required for Client to send ECHO in between messages when test is in processing? If not, ECHO message will be sent to Server only when the tester wants to check the connection status.

A: There is no specific requirement or special mode to use ECHO in between messages. It is not required but it is possible to do so.

D.3 Product Features and Configurations

Q: Our product solely supports Online only configuration (our product does not support Offline only configuration and Both Online and Offline Capable configuration), but I received the following element disabled, do I need to handle this data? <Tag ID="ONLINE_ONLY_READER_ENABLED" name="Online-Only Reader Enabled">False</Tag>

A: If your product does not support disabling Online only configuration, you do not need to handle this data. Online only configuration shall remain enabled all throughout test execution.

Q: Both the values of Transaction Type (tag 9C) for Purchase without cashback and Purchase with cashback are ’00’. How can I distinguish them to perform a transaction?

A: Transaction type (tag 9C) for both Purchase without cashback and Purchase with cashback is '00'. You can distinguish cashback amount by checking that Amount, Other (tag 9F03) value is greater than zero '000000000000'. If the value is greater than zero, the transaction is Purchase with cashback. Otherwise, it is a Purchase without cashback.

Q: Purchase with cashback have two amounts, Amount, Authorized (tag 9F02) and Amount, Other (tag 9F03) which amount shall I use for Reader Risk Processing?

A: Amount, Authorized (tag 9F02) is the amount used for Reader Risk Processing. VCPS specifications (Req 5.18, 2nd bullet) states that Amount, Authorized (tag 9F02) is the sum of the Purchase Amount and the Cashback amount (if present and known).

Q: Test 03 is by default set as NA. However, when I execute “Batch Run - Test 1 to 20”, the RC Verifier stops as Test 03 has failed. Is there a way to continue even if a test has failed?

A: In RC Verifier settings panel, uncheck the “Stop on Error” feature. This will enable the RC Verifier to continue even if a test case has failed verification.

Q: Test 01 and Test 02 are mandated to run. However, for transactions that do not end up with a 'terminate', our product sends a default outcome (i.e. always online approval). Test 01 will flag a fail as there is a mismatch in the transaction outcome. Is this acceptable?

A: It is acceptable as long as the mismatch is only at the transaction outcome and that the product's outcome is not a 'terminate' or a 'switch interface' for these tests.